home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 214 < prev    next >
Text File  |  1996-08-06  |  3KB  |  69 lines
  1. Newsgroups: comp.lang.c++,comp.lang.c,comp.std.c
  2. Path: blackbush.xlink.net!slsv6bt!slsv6bt!kanze
  3. From: kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763)
  4. Subject: Re: Hungarian notation
  5. In-Reply-To: seebs@solutions.solon.com's message of 27 Jan 1996 03:18:15 -0600
  6. Message-ID: <KANZE.96Jan29124454@slsvewt.lts.sel.alcatel.de>
  7. Sender: news@lts.sel.alcatel.de
  8. Organization: SEL
  9. References: <30C40F77.53B5@swsbbs.com> <JSA.96Jan26175507@organon.com>
  10.     <31098190.8106176@nntp.ix.netcom.com>
  11.     <4eco1g$aih@fountain.mindlink.net> <4ecqkn$p1t@solutions.solon.com>
  12. Date: 29 Jan 1996 11:44:54 GMT
  13.  
  14. In article <4ecqkn$p1t@solutions.solon.com> seebs@solutions.solon.com
  15. (Peter Seebach) writes:
  16.  
  17. |> In article <4eco1g$aih@fountain.mindlink.net>,
  18. |> Gene Wirchenko <genew@mindlink.bc.ca> wrote:
  19. |> >>I claim that ISO 6.2.1.2 requires that an implementation actually do
  20. |> >>such a conversion.  The implementor may choose the mapping.  Beside
  21. |> >>the usual throwing away of high order bits, possibilities include
  22. |> >>always using the value 0, or the largest possible value for the new
  23. |> >>type, or, even, a random value.
  24.  
  25. |> >     Implementation defined means implementation defined, not what you
  26. |> >want it to mean.  I agree that your interpretation sets out reasonable
  27. |> >actions that might be performed.  Please quote chapter and verse on
  28. |> >where the Standard states that implementation defined actions must be
  29. |> >"reasonable" (whatever the hell that is <G>).
  30.  
  31. |> Ahh, but there is the key.
  32.  
  33. |> My understanding (and I believe this is Mike's point) is that there is
  34. |> a different between implementation defined *BEHAVIOR* and an implementation
  35. |> defined *RESULT*.
  36.  
  37. |> My understanding is that integer conversions are an implementation
  38. |> defined *RESULT*.  No other *behavior* is allowed - the semantics do
  39. |> not imply or show any.
  40.  
  41.     [...]
  42. |> However, given something where the *result* is implementation defined, I
  43. |> would expect that no unexpected *behavior* was allowed.
  44.  
  45. Well, I suppose I would argue that getting a signal in such a case
  46. would be the expected behavior, so there is still no unexpected
  47. behavior:-).
  48.  
  49. In fact, given the difference in wording between this and
  50. floating-point conversions, I fear that the committee did intend to
  51. ban reasonable behavior in this case.
  52.  
  53.     [...]
  54. |> >     What if the conversion results in overflow?
  55.  
  56. |> This is actually a legitimate question; if conversion is taken to be
  57. |> an operation, then the previously pointed out limit on all arithmetic
  58. |> ops comes into play, and we have full-fleged *undefined behavior* -
  59. |> easily enough to format a disk with.
  60.  
  61. This would almost seem to forbid the check in an implicit conversion,
  62. but allow it in an explicit one (cast *operator*):-).
  63. --
  64. James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
  65. GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
  66. Conseils, Θtudes et rΘalisations en logiciel orientΘ objet --
  67.                 -- A la recherche d'une activitΘ dans une region francophone
  68.  
  69.